I was recently browsing the archives of the MIT Sloan Management Review (as one does), when I came across a fascinating article from the Fall 2018 issue titled “Breaking Logjams in Knowledge Work.”
The piece starts with a blunt observation: “If you work in an organization, you know what it’s like to have too much to do and not enough resources to do it.”
This is not accidental:
“…many leaders continue to believe that their organizations thrive when overloaded, often both creating pressure and rewarding those who deliver under duress. It’s a popular but pathological approach to management.”
The knowledge sector, it turns out, wasn’t the first to deal with a misguided commitment to overload.
“U.S. manufacturers suffered mightily under this approach for decades,” the article’s authors write, “until many found a better way.”
In the 1980s, American factory managers believed that keeping every machine and worker perpetually busy was the key to productivity: “If everybody was busy, the thinking went, the plant would produce more.”
But then more advanced manufacturing techniques, originating in Japan, spread to American factories and replaced a simplistic commitment to busyness with a much more flexible and efficient approach to production.
Though the details of modern advanced manufacturing techniques are complicated (just ask any “six sigma blackbelt”), the authors claim that some of the basic ideas from this sector can be translated to the office setting to solve the problem of chronic overload and help everyone work more productively.
In particular, they focus on the crucial shift from push to pull.
A traditional way to build things is with a push system in which you move something along a production process to the next step as soon as you’re done with it. There are two problems with this approach:
- It creates bottlenecks as certain steps in the process inevitably receive more work than they can handle, eventually slowing down everything else.
- It complicates prioritization by distributing these decisions to the individual places where bottlenecks arise, leading to a jumbled approach that often doesn’t synchronize neatly, further delaying production.
The manufacturing sector eventually realized there were great advantages to instead move to a pull system in which you pull work to your step in the process only when you’re ready for it. This approach eliminates local bottlenecks because you don’t take on work you’re not ready to handle. In addition, because backups are now concentrated at the beginning of the process, it simplifies the task of prioritizing efforts, as these decisions can be made up front in a more systematic fashion.
Factories that deployed a pull model ended up functioning more productively. The authors of this article argue that this model can deliver similarly positive results to office settings.
The specific case study they present concerned research and development at MIT’s Broad Institute. Before their intervention, Broad implicitly followed a push model in which ideas were haphazardly pursued and bottlenecks were common:
“When knowledge work processes are managed via push, it’s difficult to track tasks in process because so many of them reside in individual email in-boxes, project files, and to-do lists. Complicating matters, talented employees — particularly those in innovation-focused environments — have a knack for continually pushing more new ideas into an organization than it’s equipped to process”
To switch to a pull model, the R&D group mounted on the wall a flow chart that captured the steps required to move an idea from conception to deployment. They then represented projects as post-it notes on this flowchart, affixed to their current step in the process.
This visual tool made it simple to enforce limits on works in progress at each step by having projects be pulled from one step to the next, preventing overload. This shift made a big difference:
“The exercise led to two insights. First, there was an obvious lack of common prioritization: Nobody was aware of every project, there was little consensus about which ones mattered most, and many projects overlapped or competed with others. Second, the system had too much work in process. Comparing the number of current projects with recent delivery history showed that employees had at least twice as much work as they could complete in the best of circumstances.”
By implementing a pull system that made all of the ongoing work transparent, and placing limits on work in progress, the Broad Institute was able to significantly improve the efficiency with which they completed projects.
This shift from push to pull is just one idea among many that could help make better sense of the chaos that defines modern knowledge work. As I argued recently, the time has come to start seeking these ideas. We can no longer allow the efforts in this sector to unfold as a haphazard cascade of email messages and hastily organized Zoom calls. We need to take seriously not just how much we work, but how this work is organized.
Imagine if email worked on a “pull” system.
Thus, you check you email only when you “need” more email …
I remember watching this humorously informative video on push vs pull production during my undergrad days.
“1980’s video from HP demonstrating “Just in Time” aka “Kanban” aka “Stockless” production.
Demonstrates ideas of reducing work in progress, improving quality and other ideas associated with Kanban and Lean.”
https://www.youtube.com/watch?v=PbAStO3EMMs
That’s a fantastic video. Just substitute what they’re doing in the skit with email, meeting, and slack requests, and you realize that knowledge workers are inundated with piled up WIP, and it’s killing the throughput of the entire system.
I help startups and small businesses manage their operations as a fractional COO. This WIP problem is magnified in startups because:
1. The number of ideas exceeds the team’s capabilities,
2. It’s impossible to predict time requirements for things you’ve never done before.
To address this problem, we maintain a weekly “Operations Document” with a visual display of tasks and commitments of various projects. Inevitably this document becomes a complete WIP mess. And that’s a good thing, because it forces the team to acknowledge its limits.
Awesome thinking, thank you! I fear most British organisations, even in manufacturing, remain in the the “overload is good” mentality.
Hi Cal,
thanks for the pointer to that article. I didn’t read it yet, but from your description it sounds similar to the DevOps approach for delivering software. Although it’s specific to IT, it generalizes to an extent to knowledge work in general. I found the “DevOps Handbook” from Gene Kim, Jez Humble et al. quite informative as it contains also references to other industries like manufacturing (e.g., Theory of Constraints, Toyota’s Andon Cord, lean manufacturing). Maybe you find some references there, too.
Best regards
Andre
Amen! I was part of team that implemented the a Theory of Constraints (TOC) based production management system at our Aviation Logistics Center. We reduced our overdue work orders by 20% by simply reducing work in process by 60%. Now that I’m our headquarters, I see time as production and am trying to implement the same principles to allow my staff to focus and finish: synchronize priorities, full kit the work, max load resources, and rapidly resolve issues.
Kanban is the name for this type of system, for those who want to research it further.
I’ve used it on software development projects, and it tends to work well.
Also: If you search for “Personal Kanban” you’ll find a lot of entertaining videos about people adapting these systems to managing their individual office workloads (I did a deep dive into these for the new book I’m working on)
Cal, I am curious – are you going to change your workflow habits to more inline with this? As a fellow professor, I can see many benefits to doing this. And tell us more about the new book you are developing…
The Army Corpse of Engineers developed their Construction Quality Management program to do just what you’re describing. The official part is pretty limited–Prep Phase meetings, Initial Phase meetings, and Followup inspections–but the details…well, let’s just say there’s a reason that after you’re trained you need five years experience before you’re allowed to fly solo! This system has been widely adopted by government agencies, either de jure or because the contractors have adopted it as their SOP.
The post-it note thing speaks to me. My team has spent a fair amount of time putting together spreadsheets that function exactly like those post-it notes. If nothing else, it allows everyone to see what the next step is, and who’s responsible for it, which prevents more problems than people realize.
The factory analogy does bother me, though. A factory can precisely control inputs and outputs because they’re dealing with physical things that are the same every time. Variations in how a car is put together by the people putting it together are not considered good things. Knowledge work often isn’t like that. The inputs are unpredictable (ask any Health and Safety officer), individual contributions on the part of the worker are often accepted if not prioritized, and the outputs often are outside of the manager’s control (review by regulatory agencies, for example). I’m not sure that managing workflow in the two situations is analogous.
Your point about dealing with things that are not the same every time is actually an interesting challenge in some manufacturing environments as well. Pull is generally recommended for processes with lower variation. There are other strategies for tackling higher variety work, though none as famous as lean manufacturing. For instance, look into the job shop scheduling problem and constraint-based scheduling.
Some types of knowledge work, like IT and software development, lend themselves more to a “pull” style than others, but there are still many things we can learn from industrial engineering and optimization literature!
I wrote about information push vs. information pull back in 2012 for HBR:
https://blogs.hbr.org/cs/2012/08/how_to_break_free_from_email_j.html
I would love to know how to implement such a system in an office environment like a law office. We have to constantly bring in new work and can’t work on a “project” basis, shutting down work for a period of time, and then reopening when we are ready. Clients need help when clients need help. We have a constant push. But we do have the same bottlenecks and overload. My staff and I trying to incorporate more efficiencies into our system, and have a once a week (Monday) prioritization of what we will be getting out the door by Friday, so that as new work comes in, we are ensuring that we work together to get other work out the door. Until now, we’ve each had our own prioritization systems and worked on things as they came up/we had time/were interested. But we haven’t prioritized working as a team. I’m not sure it will be effective, but I would love to see more advice on how this type of “pull” could work in something other than IT and project-based organizations.
Great points.
Having worked on project delivery for over 20 years (and specialised in helping clients simplify their approach to delivery, for the last decade) some observations:
– A pull system (via a simple Kanban approach) can work really well
– Making work visible to all is important (see above)
– Building a culture of trust is critical to getting the best out of teams
– Communicating progress and talking through bottlenecks is key
– Have a plan/roadmap but don’t be afraid to deviate and pivot when you need to
– Doing some 80/20 analysis on what work really needs to be done will also be time well spent
– Simplify, simplify, simplify
To your point, too much of our ‘thinking’ in this space needs rethinking.
There is a culture of ‘busy for the sake of busy’ that needs breaking.
As more methodologies appear (and sell the need for more qualifications), more complexity seems to have been added. This can lead to ‘cult’ groups brewing, all arguing their case for doing things this way or that.
None of this really furthers the discussion in a sensible fashion, or helps do work that matters and lasts.
One of the best books I have read describing at an extremely detailed level about the techniques and methods to implement in a pull system is Product Development Flow. Not an easy read, but it combines variability, economics, queueing, sizing. Understanding the concepts make you view work streams completely differently. “Constant WIP” is another way to view a pull system. Pushing work will overload a system increasing wait times and queue size. Pull ensure “Constant WIP” by only allow in work that the system is capable of handling. Viewing it this way helps me visualize why costs and times are impacted differently in these two modes.
How did pull production fare in the pandemic supply chain disruptions? From what I could see in the press, not well. It would be interesting to see an updated one where stockouts of a key (if not always costly) component of production ran out and could not be reordered. Translating to the office, comparing in-person processes vs. remote work processed would be enligtheing. Also, perhaps not directly relevant to the concept itself, I couldn’t help but notice that nearly everyone in the video was a white male.